\documentclass[11pt,a4paper,spanish,openright,twoside]{report}
\usepackage[spanish,activeacute]{babel}			
\usepackage[utf8]{inputenc}
\usepackage[top=2.5cm, bottom=2.25cm, outer=2.75cm, inner=2.75cm, heightrounded, marginparwidth=2.5cm, marginparsep=0.3cm]{geometry}	%márgenes

\begin{document}

	\begin{center}
	
	\huge{RTF PLAN DE GESTIÓN DE RIESGO}
	
	\textsc{Kike Hostelería}
	\end{center}
	
	Revisión realizada por \textsc{Cauchy-Team}

\pagebreak


\begin{enumerate}
\setcounter{enumi}{-1}
	\item Formato del documento:
		\begin{itemize}
			\item El documento carece de la identificación de la versión que estamos consultando. (Encabezado).
			\item No se muestra en la página referencia al documento de trabajo ni a la sección que se está consultando. (Encabezado).
			\item No se muestra en la página la referencia al proyecto que se está revisando.
			\item Pág. 6. En el encabezado de la página aparece el riesgo que se trata, debería aparecer la sección porque lleva a error.
			\item La organización de las subsecciones no es buena, ya que como hay subsecciones de catalogación de riesgos la priorización está como punto 11, detras de una categoria de riesgos. Habría hecho una subsección de "Riesgos identificados" con una subsubsección "Cada categoría”.
			\item Faltan puntos introductorios del estándar Boehm y conclusiones.
		\end{itemize}
	\item Identificación de los riesgos:
		\begin{itemize}
			\item Deberíais identificar los riesgos, porque las listas en las que los describís en la identificación llevan a error, no sabiendo en un principio si el cuadrado es el riesgo identificado, o la clasificación en donde habéis encuadrado los puntos que serían los riesgos.
			\item Una vez entendido que los riesgos son los cuadrados, son pocos los riesgos identificados. Se podría desdoblar cada uno de los identificados en varios otros. E.g: Deficiencias del personal se puede separar en Bajas temporales y Abandono de la asignatura, que claramente tienen probabilidades y severidades muy diferentes.
			\item Añadir que son del Boehm’s Top 10 Software Risks. (Para aclarar Chapado, por ejemplo).
			\item Falta de conocimiento por parte de los componentes del equipo, que está bajo exprimir las capacidades informáticas, debería ir bajo deficiencias del personal.
		\end{itemize}
	\item Análisis del riesgo:
		\begin{itemize}
			\item Antes de comenzar a analizar los riesgos deberíais definir lo que para vosotros es la probabilidad y la consecuencia, porque si no es difícil saber si el nivel de riesgo está bien estimado.
			\item Añadir nivel de riesgo en cada riesgo individual.
			\item Falta una descripción del riesgo que lo haga más comprensible.
			\item Los riesgos Baja definitiva, abandono de la asignatura, abandono del proyecto y abandono de la carrera pueden fusionarse en uno, e.g: "baja definitiva".
			\item Baja del cliente del proyecto debería tener una severidad más alta (puedes pasar de desarrollar "un poco" a "un mucho" por ejemplo). Podría llevar consigo cambio en la especificación de requisitos y por ende el caos total.
			Idem con "poca calidad de las funciones", que implica una aplicación mal desarrollada. Se sugiere un aumento del nivel de riesgo, parece poco para lo que es.
			\item El producto no se ajusta a lo que quiere el cliente. Parece que esto es lo más catastrófico que os podría pasar ya que deberíais cambiar todo o parte de lo ya desarrollado.
			\item El cliente no sabe qué funciones debe desarrollar el producto. Aclarar a qué os referís con “tiempo”. ¿Es más esfuerzo o retraso en general?.
			\item El lenguaje no permite hacer todas las funciones. Dependiendo en qué parte del proceso te des cuenta puede ser catastrófica pero deberíais matizarlo bien en la descripción, bien con un comentario.
			\item Los programas desarrollados son muy difíciles de usar y poco efectivos. Se sugiere modificar el nombre y quitar efectivos.
			\item Falta de recursos para el desarrollo de la interfaz, el cliente considera que la interfaz es difícil de usar, al cliente no le resulta atractiva la interfaz de usuario, y el cliente decide cambiar por completo la interfaz de usuario, son cuatro riesgos cuyas consecuencias no están equilibradas, y deben ser revisadas. Se sugiere fusionar algunos riesgos.
			\item Abandono de proyecto contemplado en la subsección "Chapado" ya estaba contemplado en la subsección "Deficiencias de personal". Puede solucionarse aclarando que se refiere a un abandono por parte de todo el equipo, una cancelación del proyecto...
			\item  El cliente cambia de opinión... es mucho más habitual tener un cliente indeciso que "improbable". Es "el producto", no "el proyecto". Bajar la consecuencia.
			\item "Nuestro producto no cumple con los requisitos de rendimiento" es similar a "Las funciones son ineficientes". 
			\item "Nuestro producto no garantiza  la calidad de uso" también se podría fusionar en alguno de los anteriores "Poca calidad de las funciones".
		\end{itemize}
	\item Priorización del riesgo:
		\begin{itemize}
			\item La obtención del nivel de riesgo debería estar hecha en el mismo punto del análisis ya que es el desarrollo lógico del proceso, pasando la priorización a una tabla en donde se vea de un golpe de vista los riesgos elegidos. Esta tabla es parecida a la que teneis en el punto 11. Priorización.
			\item ¿Por qué están analizados sólo los dos primeros riesgos de los de nivel de riesgo alto?. Se sugiere dar una pequeña explicación de por qué se eligen esos y no otros.
		\end{itemize}
	\item Gestión del riesgo:
		\begin{itemize}
			\item En cuanto al orden de los puntos de la gestión parece más lógico: Prevención, Mitigación y acción de contingencia que se ajusta más al esquema temporal de ocurrencia.
			\item R1. Como prevención estaría llevar hábitos de vida saludables. e.g. no ir de botellón sin ropa de abrigo, etc. ¿Cómo contratas a otro trabajador para este proyecto?.
			\item R3: Explicar qué es la visibilidad.
			\item R5: Preguntar al profesor, no contratar a alguien con experiencia. Como solución al riesgo hay que cubrir la adquisición de conocimiento.
		\end{itemize}
	\item Conclusiones:
	
	Quedan expuestas las conclusiones en el acta de la cual este documento es adjunto.
\end{enumerate}


\end{document}